Electronic medical records information system

ABSTRACT

There is provided an apparatus for organizing a clinical observation in the form of clinical information entered by a user into memory. The apparatus includes a mechanism to receive the clinical information, which is associated with the clinical observation and has a plurality of clinical attributes. There is a mechanism for parsing the clinical information, and which identifies a clinical information data structure representative of the clinical information and which has one or more granule information data structures. Each of the granule information data structures has a collection of generic attributes. There is a mechanism to assign the clinical attributes to respective ones of the generic attributes of the one or more granule information data structures. The clinical information data structure associates the clinical attributes with respective ones of the generic attributes of each of the granule information data structures.

BACKGROUND OF THE INVENTION

1. Field of the Invention

The present invention relates generally to the field of electronicmedical records, and more particularly to an information system for thestorage, handling, processing, versioning, auditing and security ofelectronic medical records.

2. Description of the Related Art

An electronic medical record (EMR) is a term used to describe patienthealth information contained in a record for use by a physician at adoctor's office. Correspondingly, an electronic patient record (EPR)describes patient health information intended for use by the patient;and an electronic health record (EHR) describes patient healthinformation used in a hospital setting. Each of these terms is usedinterchangeably around the world, e.g. an EMR in Canada corresponds toan EPR in England. The present invention is designed to work with any ofthese record types.

The International Statistical Classification of Diseases and RelatedHealth Problems, or ICD, attempts to classify diseases and has createdcodes for a wide variety of signs, symptoms, abnormal findings,complaints, social circumstances, and external causes of injury ordisease. Every health condition can be assigned a unique category andgiven a code, up to six characters long. Categories include sets ofsimilar diseases.

For example, using ICD-9 coding, a diabetic is coded as 250. What thismeans is that when care providers communicate, “250” is understood as“diabetes”. Finer granularity is achieved by adding an extra digit, e.g.“2501” is understood as ‘Diabetes with coma’. ICD is an example of a“two-attribute granule”. That is, the code “250” and the description“Diabetes”.

Unfortunately, this is inadequate for EMR information systems for anumber of reasons. First, one can find the code to describe a diseaseonly about 50% of the time because either the correct code cannot befound easily or because a code does not exist for that condition.Second, there are no additional attributes to describe the conditionfurther. In the diabetic example, other information such as the date ofdiagnosis, severity, or whether there is any family history etc. cannotbe described within the above schema.

Systematized Nomenclature of Medicine, or SNOMED, is a systematicallyorganized collection of medical terminology covering most areas ofclinical information such as diseases, findings, procedures,micro-organisms, pharmaceuticals etc. It allows a standardized way ofindexing, storing, retrieving, and aggregating clinical data so they canbe accessed and understood by disparate medical information systems. Italso helps to organize the content of medical records, and to reduce thevariability in the way data is captured, encoded and used for clinicalcare of patients and research.

While SNOMED does a good job of defining concepts, their relationships,and primitive qualifiers in addition to providing a larger number ofmedical terms than ICD (370,000 versus 10,000), it falls short inclinical encoding as the number of attributes used to describe theencoded concept limits it. This limitation requires SNOMED to create anew concept and code for every exception that does not have an adequatequalifier to describe it.

Conventional EMR information systems comprise a relational database thatincludes a complicated assortment of interrelated tables, e.g. suchsystems can have between 500 to 4000 tables. It is well known that inorder to add a column of information to the database it will costupwards of $1 million, due to the complexity of the interrelationsbetween the tables.

Over the years a mountain of medical information has been collected inEMR information systems. There is an advantage in data mining thisinformation in order to aid diagnosis and treatment of a patient'scondition, and for statistical analysis on the medical health of thepopulation as a whole.

Complex and time consuming search queries are required in conventionalEMR information systems since this mountain of data is distributed over500 to 4000 relational database tables. This has inhibited the discoveryof medical correlations due to the sheer complexity in locatingpertinent information, and has lead to the limited access to thisinformation by health professionals and researchers due to the timeconsuming nature in performing queries on such complicated data storagesystems.

Conventional EMR information systems are static in nature with regard tothe information they store. This limitation is related to the fixednature of the relational database structure used. For example, patientdemographic information has conventionally included the name of thepatient, and their home address. As can be imagined, this informationquite often changes throughout the life of the patient. The previousname and address information is quite often discarded when the new nameand address are included in the EMR of the patient, and at the veryleast the previous historical information becomes inaccessible throughthe EMR information system.

This is problematic since quite often historical medical information maybe associated with the name of the patient, and removing the history ofthe patient's name may result in losing part of the medical history ofthe patient. There is a great disadvantage in conventional EMRinformation systems in not keeping a complete history of a patient'sEMR, and in not being able to view the state of a patient's EMR at aparticular point in time.

There is a need for an improved EMR information system that eliminatesthe complexity of conventional EMR information system relationaldatabase structures. Such an improved EMR information system wouldfacilitate data mining activities in a simple and timely manner, as wellas provide a mechanism to record and playback the complete history of apatient's EMR. In addition, such a new improved EMR information systemwould include a universal encoding methodology for the recordation ofmedical observations.

BRIEF SUMMARY OF INVENTION

In one aspect of the present invention there is provided a memory forstoring data for access by an application program that is executed on adata processing system. The memory includes a data structure thatincludes information resident in a database used by the applicationprogram. The data structure includes a clinical information datastructure that has a clinical observation associated therewith. Theclinical observation includes a plurality of clinical attributes. Theclinical information data structure includes one or more granuleinformation data structures. Each of the granule information datastructures has a collection of generic attributes. The clinicalattributes of the clinical observation mapping to the generic attributesof the one or more granule information data structures.

In another aspect of the present invention there is provided anapparatus for organizing a clinical observation in the form of clinicalinformation entered by a user into memory. The apparatus includes amechanism for receiving the clinical information entered by the user.The clinical information is associated with the clinical observation andhas a plurality of clinical attributes. There is a mechanism for parsingthe clinical information entered by the user and a mechanism foridentifying a clinical information data structure representative of theclinical information entered by the user. The clinical information datastructure is associated with the clinical observation and has one ormore granule information data structures. Each of the granuleinformation data structures has a collection of generic attributes. Theapparatus further includes a mechanism for assigning the clinicalattributes of the clinical information to respective ones of the genericattributes of the one or more granule information data structures. Theclinical information data structure associates the clinical attributesof the clinical information with respective ones of the genericattributes of each of the granule information data structures.

In another aspect of the present invention there is provided anapparatus for versioning clinical information in an electronic medicalrecords information system. The apparatus includes mechanisms forretrieving existing clinical information from a first location in amemory store and for presenting the existing clinical information to auser. There is a mechanism for receiving a signal from the user toversion the existing clinical information. The apparatus also includes amechanism for copying the existing clinical information as a version toa second location in the memory store. The second location in the memorystore contains one or more versions of the clinical information.

In another aspect of the present invention there is provided anapparatus for visually playing back versioned information to a user in agraphical user interface. The apparatus includes a mechanism fordisplaying a version of the versioned information to a user in thegraphical user interface. There is a mechanism for selecting a differentversion of the versioned information including a slider control. Theslider control is displayed in the graphical user interface. The useradjusts the slider control thereby providing a version selection signal.The apparatus also includes a mechanism for retrieving the differentversion of the versioned information. The mechanism for retrievingreceives the version selection signal and retrieves the differentversion. The mechanism for displaying displays the different version.

In another aspect of the present invention there is provided anapparatus for clinical contextual encounter between a patient and aclinician in an electronic medical records information system. Theapparatus includes a mechanism to receive new clinical informationrelated to the patient into the electronic medical records informationsystem. A mechanism is provided to recognize a fundamental unit ofmedical observation of the new clinical information. There is also amechanism to retrieve historical clinical information related to thepatient from a memory store. The historical clinical information is ofthe same type of the fundamental unit of medical observation. Theapparatus further includes a mechanism to present the new clinicalinformation and the historical clinical information to the clinician,whereby a trend in the fundamental unit of medical observation isthereby displayed. The apparatus may include a mechanism to analyze thenew medical information and the historical medical information and toprovide an opinion or a diagnosis.

BRIEF DESCRIPTION OF DRAWINGS

The invention will be more readily understood from the followingdescription of preferred embodiments thereof given, by way of exampleonly, with reference to the accompanying drawings, in which:

FIG. 1 a is a network diagram view of an electronic medical recordsinformation system according to one embodiment of the present invention;

FIG. 1 b is a block diagram of a thick client application architectureon a client machine of the electronic medical records information systemof FIG. 1;

FIG. 2 is a block diagram view of a granular class of the electronicmedical records information system of FIG. 1;

FIG. 3 is a block diagram of a derived granule algorithm of theelectronic medical records information system of FIG. 1;

FIG. 4 is a block diagram of an implicit granule algorithm of theelectronic medical records information system of FIG. 1;

FIG. 5 is a block diagram view of a clinical category class of theelectronic medical records information system of FIG. 1;

FIG. 6 is a block diagram of a relationship between a clinical categoryobject and granule objects of the electronic medical records informationsystem of FIG. 1;

FIG. 7 is a class diagram of clinical category classes of the electronicmedical records information system of FIG. 1;

FIG. 8 is a computer listing of a diagnosis clinical category class ofthe electronic medical records information system of FIG. 1;

FIG. 9 is a block diagram view of a database file of the electronicmedical records information system of FIG. 1;

FIGS. 10, 11, 12 and 13 are block diagram views of rows in a clinicaltable of the database file of FIG. 9;

FIG. 14 is a simplified listing of column definitions of the clinicaltable of FIG. 9;

FIGS. 15 and 16 are block diagram views of rows of the clinical table ofFIG. 9 illustrating versioning of electronic medical records;

FIGS. 17, 18 and 19 are block diagram views of a slider control of thethick client application of FIG. 2;

FIG. 20 is a computer listing of common generic attributes of thegranule class of FIG. 2; and

FIG. 21 is a flowchart diagram of a contextual encounter algorithm ofthe thick client application of FIG. 2.

DESCRIPTION OF THE PREFERRED EMBODIMENTS

Referring to the figures and first to FIGS. 1 a and 1 b, there is anelectronic medical records (EMR) information system generally indicatedby reference numeral 100. The EMR information system 100 comprisessoftware and hardware components in a distributed environment, for thestorage, handling, processing, versioning and security of electronicmedical records.

In a simplified environment there are client machines 110 and 120, whichin the present example are personal computers, and a database servermachine 130. In other embodiments there can also be an applicationsever. The client machine 110 and the database server 130 are collocatedin a data center 125. The client machines 110 and 120 run a thick-clientapplication 115 in the present example, but in other examples they canrun a thin client web browser for communication with the applicationserver. The client machines 110 and 120 are in communication with thedatabase server 130 over private and public IP networks in order toexchange EMR information.

The client machines 110 and 120 present a graphical user interface 135to a user which in combination with application logic 145 allows a userto view, modify and add EMR information. An existing EMR is retrievedfrom the database server 130, and any additions or modifications aresent from the client machines 110 or 120 back to the database server130.

The present invention introduces a novel approach to the management ofclinical information from clinical observation to an EMR. This includesa novel approach to recordation of a unit of medical observation,commonly called a granule. A collection of granules is collected into alarger unit called a clinical category which encapsulates clinicalinformation and comprises one or more medical observations. The clinicalcategory forms the basis of an EMR, and serves as the fundamental unitof storage. The EMR exposes certain key information that is descriptiveof the EMR, which facilitates database queries. The EMR alsoencapsulates a mechanism for the versioning without loss of historicaldata. Each of these topics will be described in detail below.

Granule Class

Referring to FIG. 2 we now discuss the novel approach to the recordationof the fundamental unit of medical observation known as the granule. Thespecifics of the data structure used to store and handle the granuleconsists of a granule class indicated generally by reference numeral140, which includes a collection of common generic attributes 150. Thegranule class 140 inherits a base class 160, which includes most of thelogic that handles the basic housekeeping tasks, which will be discussedin more detail below. Most classes in the EMR information system 100inherit the base class 160.

The granule class 140 is coding system agnostic. Any coding system maybe embedded within it. One of the attributes 150 of the granule class140 is “CODING SYSTEM” and can be assigned a value of “ICD”, “SNOMED”,or any other coding system. Therefore, existing coding systems can becombined with the additional capabilities of the granule class 140. Infact, a coding system is chosen to best meet the needs of the type ofclinical capture. For example ICD or SNOMED may be used to capturediagnoses, Logical Observation Identifiers Names and Codes (LOINC) maybe used to capture laboratory values, and locally developed billingcodes may be used for billing etc. No matter what the coding system, theattributes 150 of the granule class 140 remain the same in order toreduce the variability of description and consistency of storage.

The generic attributes 150 can be extended to include new attributes.The concept of the granule class 140 is to extend the number ofattributes until a saturation state is achieved, i.e. there are no morequalifiers needed to describe every possible unit of clinicalobservation, or clinical attributes, known to medicine. Referring toFIG. 20, there are approximately eighty-four defined attributes 150within the granule class 140. It is expected that there will be close totwo hundred attributes 150 before saturation is achieved. While not allthe attributes 150 have been identified thus far, the inherentextensibility of the granule class 140 allows additions to be made asthey are discovered without adversely affecting those stored in legacysystems, as will be discussed in more detail below.

Many of the attributes 150 satisfy not only a need to better define aclinical observation, but also solve existing problems in informationsystems. Therefore, the granule class 140 should not be consideredpurely clinical but informational/clinical. For example, while SNOMED isthe most elaborate method developed thus far to describe clinicalfindings, it falls short in conveying a multitude of additionalinformation items. In contrast, the granule class 140 is a single datatype class, which is capable of containing all these additionalinformation items and of enforcing consistency of expression of allpossible clinical observations. The utilization of the granule class 140achieves the necessary granularity and allows highly complex clinicalobservations to be handled in a simple and consistent way by healthinformation systems.

Further, one of the attributes 150 is a globally unique identifier(GUID), which uniquely identifies each of the granules 140 such that notwo granules are the same in any information system. The GUIDs ensurethat back-ups and replications of clinical observations do not becomemistaken for a number of distinct observations when they actually referto a single observation. For example, when many health providerscollaborate in patient treatment, a single lab value may be copied toseveral providers for their perusal. The GUID attribute of the granulesclass 140 ensures that copies of a single lab observation are notconfused with multiple lab observations instead. Clearly, such confusionmay have unintended and potentially dangerous consequences to patientcare. The ISCOPY and ISCOPYOF attributes of the granule class 140enforce this concept by explicitly noting it to be a copy of an existinggranule.

The granule class 140 includes attributes for the following data items:a specific Name, a Value, Units, a Keyword, the context in which theobservation was made, a coding system and its code, body specifics, aseverity, an emphasis, etc., which are included in the collection ofattributes 150. Depending on the clinical observation, some or all ofthe attributes 150 of the granule 140 may be assigned a value.

A granule may be derived from existing granules, in which case theattribute ISDERIVED is set true. For example, referring to FIG. 3, abody mass index is commonly calculated from a weight and a height. Bothheight and weight are separate clinical observations and reside inrespective granules 170 and 180. Note that the granules 170 and 180 areinstances of the granule class 140. The two granular entities 170 and180 can be combined by way of calculation using formula 190. In thepresent example the calculation is based on the weight divided by thesquare of the height to create a new body mass index (BMI) granule 200.The BMI granule 200 is then said to be derived from the height andweight granules 170 and 180 respectively. The EMR information system 100is designed to automatically create such derived granules by using knownand accepted formulae 190.

Derivative granules are important to the future of medicine, andcomputing provided by automated features may be utilized in clinicaldecision support. The ISDERIVED BMI granule 200 includes an attributecalled ISDERIVEDFROM, which is an array of references (GUIDs) to theintegral granules. In the above case, therefore, the array would simplycontain GUID references to the height and weight granules 170 and 180respectively. This is one of the key features of the granule 140, whichenables sharing and interoperability.

The BMI granule 200 can then be shared with other providers withouttransferring its integral granules, i.e. the height and weight granules170 and 180 respectively. However, in transferring the BMI granule 200 areference to the height and weight granules remains in the ISDERIVEDFROMarray. If the provider who received the BMI granule 200 requires theactual height and weight values from which the BMI granule was derived,and if appropriate trust permissions are set up between the providers,then the source granules may be obtained by querying back without theneed of the sending provider to deal with the request physically.

In providing a solution to interoperability, the specifics of the queryback-trust mechanism have tremendous potential to save administrativehealth care dollars by avoiding the need for multiple contacts andcommunications between providers and/or institutions. With reference toFIG. 20, the granule class 140 has ISSUMMARY, ISNEWFINDING, andISSUMMARYFROMSOURCE attributes, which help to avoid confusion ofreplicated information in an interoperable health care world.

The nature, quality, and reliability of clinical information obtainedfrom interviews can often be incorrectly or inadequately captured due tolack of additional qualifying information. For example, qualifyinginformation may indicate whether the information was obtained directlyfrom the patient or relayed by other sources. Information sources areoften from other providers or delegates of the patient such as familymembers or friends. The attributes 150 of the granule class 140 tohandle these scenarios are ISCLIENTSUBJECTIVE andISCLIENTDELEGATESUBJECTIVE. The findings may be explicitly noted to be afinding of a particular nature, i.e. ISNEGATIVEFINDING,ISPOSTIVEFINDING, ISNORMAL, ISABNORMAL and ISABNORMALFLAGS.

The granule class 140 includes a TIME or TIMESPAN attribute. The datesof historical information may be vague or approximate as indicated bythe DATECERTAINTY, ISRESOLVED, and DATERESOLVED attributes, and thedescription may relate to time as in ISPAST, ISPRESENT, and ISFUTURE.

Referring to FIG. 4, granules may be created explicitly or implicitly.By way of example, a lab result is captured in an explicit granule 210encapsulating a blood glucose level clinical observation. The EMRinformation system 100 would perform a diagnosis 220 on the explicitgranule 210, and depending upon the blood glucose level could result ina diagnosis of diabetes. An implicit granule 230 is created and isflagged as ISIMPLICT rather than ISEXPLICIT.

The implicit diabetes granule 230 is created dynamically by the EMRinformation system 100, and is a ‘diagnosis granule’ containing thediabetes diagnosis. The diabetes granule 230 would then automaticallyand transparently trigger a series of recommendations that clinicianswould need to perform in order to treat this condition in concordancewith accepted treatment guidelines. The recommendations are expressed asadditional treatment granules 240. The consistent way in which thesevarying clinical entities are stored avoids ambiguity and uncertaintythat may arise when dealing with clinical categorization and lendsitself to easy reuse of data and elimination of unnecessary duplication.

Various housekeeping features within all granules include attributessuch as: ISHELD, ISREFERRAL, ISPENDINDINGSUBMISSION, ISSUBMITTED,ISREPORTED and ISRESULT, which provide a generic way of documentinggranules that are action based, i.e. test orders, billings, etc. Theprefix “IS” followed by a noun or phrase describing a quality, as usedin the attributes above and other attributes within the granule class140, indicates that the attribute has that quality if the attribute isassigned a logical true value.

The structure of the granule class 140 incorporates broad categoryclinical observations by means of the attributes 150 such as:ISEXAMINATION, ISTESTORDER, ISLABORDER, ISRADIOLOGYORDER,ISPRESCRIPTIONORDER, ORDERTYPE and ISREFERRAL.

Clinical Category Classes

Referring now to FIGS. 5, 6 & 7, a clinical category storage mechanismis discussed. Broad clinical observations are called clinicalcategories, and are encapsulated in the clinical category classindicated generally by reference numeral 300. The clinical categoryclass 300 inherits the base class 160, in the present example, andincludes a collection 310 of granule objects 320 and an embeddedEntity-Attribute-Value (EAV) database 330. The granule objects 320 areinstances of the granule class 140.

An instance of a clinical category class 300 is a clinical categoryobject (CCO) 340 which includes one or more of the granule objects 320.Each CCO 340 represents the fundamental unit of the EMR, and comprisesone or more granule objects 320, which represent the fundamental unit ofmedical observation. Each CCO 340 is stored within a single database rowentry, as will be discussed in more detail below.

The clinical category class 300 associates, or maps, clinical attributesof one or more clinical observations to the generic attributes ofrespective granule objects 320. The collection 310 of all the CCOs 340is considered to be a granular layer. The granular layer provides anefficient mechanism for running advanced queries on the database, whichis discussed in more detail below.

The granules 320 are agnostic of or dissociated from the clinicalattributes of the clinical observation represented by the clinicalcategory object 340 from which they are derived. The attributes of asingle granule give it the ability to describe any clinical observationthat may arise, including its characteristics and the circumstances inwhich it was formed.

The granules 320 in turn inherit attributes of the base class 160.Therefore, the granules 320 are infinitely extensible and capable ofresponding to changes in medicine by their ability to alter and createclinical categories. The above structure gives the EMR informationsystem 100 the ability to evolve as it were, without having to redesignor to re-work the framework or architecture of the application.

The base class 160 within the clinical category class 300 provides amechanism to add new attributes to the granule class 140 withoutaltering either the granule class 140 or the clinical category class300. Keeping the clinical category class 300 definition relativelystatic also ensures that serialization into persistent storage ispossible and remains consistent. Most of the attributes 150 seen in FIG.20 are defined through the use of a Property statement of theprogramming language, in the present example VB.Net. The Propertystatement makes use of GET and SET procedures created for the attainmentand assignment of values respectively. When a value is sought for any ofthe attributes 150 described above through the GET procedure, it calls afunction in the base class 160 to find it in the embedded EAV database330.

The EAV database 330 is necessary due to the vastness of the number ofthe attributes 150 in the granule class 140 of which many, as mentionedearlier, may not be known until the EMR information system 100 has beenused in actual settings for some time. As the number of the attributes150 grow, these attributes would simply be added to the EAV database 330embedded within the base class 160.

Note that only the assigned attributes 150 through the SET command arestored in persistent storage. The GET procedure for an attribute 150that is not assigned in the current granule object 320 simply returns adefault value and does not take up persistent storage space.

The base class 160 in the clinical category class 300 provides amechanism to store any number of granule objects 320 within the CCO 340,again without altering the class structure of the clinical categoryclass. The granule collection 310 provides the mechanism to create newgranule objects 320 as needed by the clinical category object 340.

The base class 160 provides an ability to associate with other clinicalcategory classes 300 in a hierarchical, parent/child fashion therebypermitting this hierarchical structure in a flat file. Referring to FIG.7, child clinical category classes 350 and 360 inherit parent clinicalcategory class 370 which in turn inherits the base class 160; and theclinical category class 300 is shown inheriting the base class 160. Thebase class 160 manages the hierarchical structure and through the EAVdatabase 330 provides a mechanism to extend a clinical category toinclude new variables in a dynamic fashion without changing thestructure of persistent storage, or preventing legacy software fromfunctioning.

The clinical category class 300 clusters similar smaller medicalobservations described within the granule objects 320 into larger, moreeasily manageable clinical category objects 340. Examples of clinicalcategory classes include patient demographics, drugs, lab tests, orders,etc. New clinical category classes can be created without affectingother clinical category classes.

Referring to the code block in FIG. 8, a Diagnosis clinical categoryclass 380 is defined as xDiagnosis, which, by convention, inherits thebase class 160. The Diagnosis clinical category class 380 includes onegranule object 320 which holds the diagnosis, returned as “G” in theprogramming language. The procedural call _Aux(0) is a call to retrievethe granule object 320 located at position zero in the granulecollection 310.

Typically, a user will enter diagnosis information which is parsed bythe application logic 145 seen in FIG. 1 b. The application logic 145then instantiates a clinical category object from the clinical categoryclass 380 by calling the method New indicated by reference numeral 390.The New method 390 associates, or maps, the clinical attributes of thediagnosis clinical observation to the granule object 320 by assigningthe clinical attributes to respective ones of the generic attributes ofthe granule object 320. This does not preclude this CCO from holdingmore than one diagnosis. Most CCO's would hold many granules.

Persistent Storage—Clinical Table

Referring now to FIGS. 1 a, 1 b and 9, the persistent storage used inthe EMR information system 100 is now discussed in more detail. Thedatabase server 130 includes a database in the form of a flat file 500.The flat file 500 includes clinical table 510 comprising patientinformation, i.e. the electronic medical records (SMRs), and referentialtable 520 comprising fixed information, e.g. billing and diagnosticcodes.

There is also an update table 530 and a live table 540, which are usedto exchange information and resolve changes made between, for example,the thick client application 115 on the client machine 120 and the dataserver 130 in the data center 125. This is particularly useful after thethick client application 115 has been operating in a “disconnected” or“stand alone” state.

The storage method used for clinical information does not require anycross-references to child or relational tables as typically employed inrelational databases. The EMR information system 100 stores patient EMRsof an entire organization in the single clinical table 510. Clinicalcontent includes, but is not limited to, patient demographics, problemlists, medical history, encounters, medications, lab and radiology testsresults etc.

As mentioned above, the clinical category object (CCO) 340 is organizedin an objected-oriented hierarchical structure providing a complexrelational structure. The CCO 340, which describes an entire clinicalcategory, is stored by serialization as a single binary field into onecolumn of a single row of the clinical table 510 in the flat file 500.Each CCO 340 occupies its own row in the clinical table 510. Versioneddata, i.e. fixed temporal copies of the CCO 340, reside in a separatebinary field stored in an adjacent column of the same row. Other columnsin the clinical table 150 include meta-information describing theinformation in the binary fields.

A patient's medical record is represented by a collection of row entriesin the clinical table 510, which includes defined clinical categoryobjects (CCO) 340, such as demographics, medical history, physicalexamination findings, progress notes, lab results, prescriptions etc.The patient's medical record can be built by retrieving all the CCOs 340that are identified as belonging to a particular patient. All such CCOs340 are identified as belonging to the particular patient by way of apatient GUID stored as another column in the clinical table 510.

The EMR information system 100 is database agnostic in the sense that itmay store data within disparate database systems such as SQL, ACCESS,ORACLE, SYBASE, INTERBASE, and others. Further, the EMR informationsystem 100 is capable of storing data in more than one database systemsimultaneously and in fact does so as part of its normal operations.This is achieved through the ability to store all clinical observationdata in a simple manner in the clinical table 510. This feature uniquelyenables the EMR information system 100 to be easily deployed ondisparate systems that may utilize their own preferred databases.

Clinical categories are subject to change and new categories may need tobe defined due to the constantly changing and evolving nature ofmedicine. New categories of clinical information can be handled withoutmodifying the structure of the clinical table 510 or changes to theexisting data therein. Recall that conventional EMR information systemsemploy relational table data relationships, and new clinical categoriesin these systems require typically both new tables and changes toexisting tables.

The structure of the clinical table 510 lends itself to adapting to theever changing needs of clinical information systems. Thus by design, theEMR information system 100 is not dependent on the peculiarities of eachdatabase management system, rather it is able to transgress multipledatabase management systems without fear of loss of data integrity.

In addition, no matter what content may exist in these new clinicalcategory classes, storage and handling is done in a consistent manner byway of a direct 1:1 mapping of each of the CCOs 340 to a row in theclinical table 510. The type of the CCO 340 is identified by a column inthe clinical table 510 called “Segment”, which is unique for each typeof CCO.

All changes made to a CCO entry in a patient's record are recordedwithin the same row in which the data resides, including changes totemporal and user information so that information is never deleted froma patient's record and a complete history is available at all timesincluding additions, modifications and logical deletions. It is possiblefor a user to play back and roll back changes when deemed necessary.Duplication of a single row in the clinical table 510, therefore,results not only in the duplication of the current data but alsoduplicates the complete history of changes leading up to the currentstate. These are important auditing and versioning features, describedin more detail below.

A security method locks down the EMRs with an encryption and compressionpolicy to protect the sensitive clinical information. Each row of theclinical table 510 is marked with a globally unique identifier (GUID) toallow subsets of the master table to be distributed, processed andmodified in a disconnected fashion. For example, a copy of the flat file500 can be exchanged between the database server 130 and the clientmachines 110 and 120. Changes are resolved by performing a match to theGUID of the replicated row and analyzing the data versions encapsulatedin the row.

Examples of CCO Storage

Referring now to FIGS. 10 to 14, examples of storing the CCOs 340 in theclinical table 510 are shown. FIG. 10 shows a simplified view of a row600 of the clinical table 510, showing metadata 610 and the diagnosisclinical category object 380, for example. The clinical category object380 has one granule, the granule object 320.

FIG. 11 illustrates a CCO 620 representing an examination that is partof a clinical encounter that holds a blood pressure granule 630, theheight granule 170, the weight granule 180, and the BMI granule 200. Thegranules 170, 180, 200 and 630 are stored in the granule collection 310in the base class 160, seen in FIG. 5.

FIG. 12 illustrates an electronic medical record having a patientdemographic CCO 640, a referral CCO 650, and two diagnoses CCOs 660 and670. Each of the above CCOs 640, 650, 660 and 670 occupies their own rowin the clinical table 510 seen in FIG. 9.

FIG. 13 illustrates how CCOs belonging to many different patients residein the same clinical table 510. Patient GUID 680 is one of the metadatacolumns, which identifies each CCO object as belonging to a particularpatient, such that a query using the patient GUID returns the entirepatient's electronic medical records containing all objects tagged withthe same GUID.

Persistent Storage—Referential Table

Referring again to FIGS. 1 a and 9, the database server 130 in thedatacenter 125 is delegated to hold the original footprint of thereferential table 520, as the sole and authoritative source of all fixedor referential elements in the EMR information system 100. These fixedelements refer to codes and their descriptions contained in variouscoding systems, dictionaries, and indexes such as list of fees inbilling systems, provider names in a provider index and so on.

The referential table 520 is easily updated and replicated as it is asolitary flat table. It is by design as flexible and extensible as theclinical table 150 described above. For example, new coding dictionariesand standards used in medical practice in any particular location or atany particular time may be easily changed or added without the need formodifying the EMR information system 100.

The proper functioning of the EMR information system 100 requirescontinuous access to these fixed elements in the referential table 520whether they are accessible remotely or locally. The preferred method isto access these fixed elements locally, for example from within thethick client application 115 on the client machine 120. This allows theEMR information system 100 to operate without a connection between theclient machine 120 and the database server 130. This is achieved byreplicating the referential table 520 from its original footprint toevery system that needs access to it.

Changes within the referential table 520 are typically made at thedatacenter 125, which represents the highest organizational level.Changes made to entries in any of the fixed element collections can thenbe reflected back to all systems that depend on it for current and up todate information. Just as DNA, present in each cell of the human body,holds an entire copy of the human genetic code, so does each instance ofthe EMR information system 100 application hold a copy of thereferential table 520, which can be thought of as the ‘genetic code’ ofEMR information system 100.

The thick client application 115 on a client machine 120, seen in FIG. 1b, can be thought of as a cell in the human body having a private copyof the referential table 520, or its DNA. This method lends itselfeasily to distributed processing of medical context, for which the EMRinformation system 100 is designed.

The update table 530 and the live table 540 comprise entries relating tothe changes in the referential table 520 so that changes in each systemcan be resolved through the updating code within the EMR informationsystem 100. This ensures that the referential table 520 remainsidentical in each and every system. In the present example the thickclient application 115 polls the database server 130 independently forchanges in the referential table 520. However it is possible that inother examples the database server 130 can push changes to the clientmachines 110 and 120.

The EMR information system 100 also has the capability of automaticallypolling some of the data sources for changes. Any such changes in thedata source will automatically update, add or delete their associated orrepresentative entries in the referential table 520. This enables thetransparent handling of common situations in the heath care field, forexample, new or discontinued drugs, new or retired providers, changes inproviders' contact information, etc. This provides EMR informationsystem 100 users with current and up to date referential, or fixed,information.

The thick client application 115 on the client machine 120 can continueto function based on its copy of the referential table 520 stored in alocal database alongside the thick client application 115. This isadvantageous during situations that require either a disconnected state,or when connected systems experience a loss of connection to thedatacenter 125 or other dependent servers. While updating cannot occurduring a disconnected state, updating occurs automatically uponreconnection. Resolution of entries in the referential table 520 isdetermined by the information recorded in the update table 530 and thelive table 540 described above.

The structure and the function of the referential table 520 is similarto that of the clinical table 510 used for storage of patient-specificclinical information. The clinical table 510 differs by having anadditional column to deal with attributing CCO's to a specific clinicalencounter.

Database Queries

Referring to FIG. 14, queries on the clinical table 510 are nowdiscussed. The EMR information system 100 utilizes citation key fieldsindicated generally by reference numeral 700, which are metadata columnswithin the clinical table 510. The keys 700 which are generated arechosen from the content of the CCO 340 requiring exposure to querying.

For example, a demographic CCO may expose the surname, and a diagnosisCCO may expose the ICD-9 diagnostic code. A referral CCO may expose theprovider number of the physician receiving the referral. The clinicaltable 510 includes six citation key fields 700. However, this isextensible if necessary.

As mentioned above, the granular layer is embedded within the CCOs 340so that deprecation is inherent throughout the entire clinical table510. The granular layer can be sorted via a combination of directmapping rules, or by inference through recognizing patterns in thegranular layer.

Referring now to FIGS. 1 b, 2, 9 and 21, a contextual encounter isdescribed. A contextual encounter of a patient in a medical facilityinvolves a clinician collecting current clinical information related tothe patient, retrieving historical clinical information of the sameclinical category and relevancy, and presenting the current and thehistorical contextual clinical information to the clinician.

The clinician enters clinical information related to the patient in step875 of the thick client application 115 of the EMR information system100. The clinical information is parsed by the thick client application115 and at least one new clinical category object and corresponding newat least one granule object is created representative of the clinicalinformation in step 880. The new clinical category objects and the newgranule objects are stored in the clinical table 510.

Considering now one of the new granule objects, a recognition algorithmof the thick client application 115 searches the clinical table 510 forall historical granule objects in the patients electronic medical recordof the same fundamental type of clinical information as the new granuleobject in step 885. The thick client application 115 performs ananalysis on the new granule object and the historical granule objectsand generates an opinion, or a diagnosis in step 890. The current andthe historical granule objects are dynamically displayed to theclinician in step 895, for example in a tabular or graphical format,thereby showing any trend that may exist. The patient encounter ispersisted in the clinical table 510 as an encounter clinical categoryobject, and has associated with it a context encounter.

As a practical example, the clinician types into the thick clientapplication 115 the textual string “BP 120/80” representing the bloodpressure of the patient. The thick client application 115 creates ablood pressure granule object holding the value “120/80”.

Simultaneously, the thick client application 115 obtains a collection ofall previously persisted historical blood pressure granule objects inthe patient's electronic medical record within the clinical table 510. Agraphical view showing the trend in blood pressure of the patient ispresented to the clinician based on the new and historical bloodpressure granule objects. Next, the clinician may enter a weight intothe thick client application 115. The context is now changed, and thethick client application 115 responds in the manner presented above anddisplays historical contextual weight information. The enforcedconsistency of recordations of the clinical observations into granuleobjects is the foundation for such behavior.

Versioning

Referring now to FIGS. 15 and 16, the versioning process is nowdiscussed. FIG. 15 illustrates a row 800 in the clinical table 510 whichincludes a referral CCO 810. The versioning process works by creatingand maintaining an MD5 hash 820, which is stored in a DATA_HASH column830 within metadata section of columns indicated generally by referencenumeral 840. The MD5 hash represents the contents of the referral CCO810.

During the normal use of the EMR information system 100 the referral CCO810 may be edited or updated, creating a new referral object 850. justbefore an update to the row 800 in the clinical table 510 occurs, a newMD5 hash 860 is calculated for the new referral CCO 850. If the new MD5hash 860 is different than the old MD5 hash 820, the old referral CCO810 is placed into a VERSIONSX metadata column 870. The VERSIONSX column870 comprises a serialized object that stores all previous versions ofthe referral CCO object 850 along with the state of all of the metadata.Copying the row 810 of the clinical table 510 to another database hasthe effect of copying the current referral CCO 850 along with all of itsprevious versions. Since versions of a CCO reside within the same row ofthe clinical table 510 as the current CCO, relational database entriesare not required.

Referring now to FIGS. 17, 18 and 19, the selection and playback ofversions are discussed. The client machines 110 and 120 are used by theEMR information system 100 to present a graphical user interface to auser in order to view, modify and add EMR information. The graphicaluser interface visualizes the contents of the clinical category objects340 to the user, and includes a slider control indicated generally byreference numeral 900 in FIGS. 17, 18 and 19.

Versions of the CCOs 340 are displayed interactively to the user byadjusting the slider control 900 such that the appropriate version isselected, as indicated by version selection text 910. The slider control900 enables the instant visual playback of all the previous versions ofclinical observations in chronological order. In addition, the slidercontrol 900 presents information relating to the entity 920 responsiblefor the version as well as the detailed timestamp 930 of each version,such that the viewer can visually determine in real time what changeswere made, by whom they were made, and when they were made.

Database Kernels

Referring again to FIG. 1 b, the interface between the thick clientapplication 115 and the flat file database 500 is now discussed. Thethick client application 115 interfaces to the clinical table 510 andthe referential table 520 through a clinical kernel 515 and areferential kernel 525 respectively. The operation of the two kernels515 and 525 are similar in most respects.

The architecture of the EMR information system 100 constrains access tothe data in the two tables 510 and 520 through the respective kernels515 and 525. This enforcement allows for the application 115 to queryand save data in a consistent manner and to enable the inherent featuresof the kernels 515 and 525 to be transparent and separate to the userinterface. The functions that the kernels 515 and 525 provide aredescribed next.

The kernels 515 and 525 provide querying functions in order to returnthe entire medical record of a patient. The patient's record is obtainedby querying the GUID in the patient GUID column of the clinical table510, as shown in FIG. 13 for example. The query returns all the CCO's inpersistent storage for the particular patient.

The kernels 515 and 525 track users, organizations and the authoring ofeach CCO. Each CCO is stored with metadata as previously described. Themetadata includes the above information based on the user who loggedinto EMR information system 100.

The kernels 515 and 525 provide functions to handle citation keys ofeach CCO 340. As CCO's are stored as a serialized binary field, they arenot exposed to querying in the clinical table 510. The citation keys 700shown in FIG. 14 are created to expose certain parts of a CCO into the‘key’ columns so they can be subsequently queried.

The kernels 515 and 525 provide functions to save CCO's 340 to eitherthe clinical table 510 or the referential table 520. The kernelsphysically save the data into the database with the assistance of a 3rdparty persistent storage class.

The kernels 515 and 525 provide functions to direct the storage to aparticular server. The user is not necessarily aware where the data isstored. The kernels 515 and 525 are able to detect and maintain thelocation of the persistent storage depending on circumstances,particularly with that of disconnected states.

The kernels 515 and 525 detect whether the user viewing the CCO has madechanges to it. With appropriate permissions, the user is able to makechanges to the fields and granules of a CCO. The kernels 515 and 525 areable to detect any changes made within the CCO.

The kernels 515 and 525 provide functions to determine whetherversioning of the CCO is required. In conjunction with detection,versions reside within the same row but in a separate CCO.

The kernels 515 and 525 provide functions to handle the versioningprocess. For example, functions to store a versioned CCO into the samerow as the current CCO.

The kernels 515 and 525 provide functions to serve versioned CCO's forplayback to the user. The kernels provide access to all the previousversions of a CCO, such that the user can examine them through theunique playback method.

The kernels 515 and 525 provide functions to update and resolve CCO'sbetween applications, i.e. the ability to resolve changes made to oneCCO and to update its replicas.

The kernels 515 and 525 provide functions to animate some interfaceprimitives like buttons, e.g. to animate buttons with colors to indicatethe actions taken by the kernel.

The kernels 515 and 525 provide functions to secure the CCO byencrypting it.

While preferred embodiments of the present invention have beendescribed, it is to be understood that the embodiments described areillustrative only and the scope of the invention is to be defined solelyby the appended claims when accorded a full range of equivalence, manyvariations and modifications naturally occurring to those of skill inthe art from a perusal hereof. As is readily apparent the system andmethod of the present invention is advantageous in several aspects.

1. (canceled)
 2. (canceled)
 3. (canceled)
 4. (canceled)
 5. (canceled) 6.(canceled)
 7. (canceled)
 8. (canceled)
 9. (canceled)
 10. (canceled) 11.(canceled)
 12. (canceled)
 13. (canceled)
 14. (canceled)
 15. (canceled)16. (canceled)
 17. (canceled)
 18. A carrier wave embodying a computerdata signal representing sequences of statements and instructions which,when executed by a processor cause the processor to version an existingclinical information data structure, the statements and instructionscomprising the steps of: retrieving existing clinical information from afirst location in a memory store; presenting the existing clinicalinformation to a user; receiving a signal from the user to version theexisting clinical information; and copying the existing clinicalinformation as a version to a second location in the memory store, thesecond location in the memory store containing one or more versions ofthe clinical information.
 19. A computer program product, comprising: amemory having computer readable code embodied therein, for execution bya CPU, for versioning an existing clinical information data structure,said code comprising: retrieving code means for retrieving existingclinical information from a first location in a memory store; userinterface code means for presenting the existing clinical information toa user; versioning signal receiving means for receiving a signal fromthe user to version the existing clinical information; and versioningcode means for copying the existing clinical information as a version toa second location in the memory store, the second location in the memorystore containing one or more versions of the clinical information. 20.An apparatus for versioning clinical information in an electronicmedical records information system comprising: means for retrievingexisting clinical information from a first location in a memory store;means for presenting the existing clinical information to a user; meansfor receiving a signal from the user to version the existing clinicalinformation; and means for copying the existing clinical information asa version to a second location in the memory store, the second locationin the memory store containing one or more versions of the clinicalinformation.
 21. The apparatus as claimed in claim 20, further includingmeans for generating a hash.
 22. The apparatus as claimed in claim 20,further including means for comparing hash values.
 23. A method ofversioning clinical information in an electronic medical recordsinformation system comprising the steps of: retrieving existing clinicalinformation from a first location in a memory store; presenting theexisting clinical information to a user; receiving a signal from theuser to version the existing clinical information; and copying theexisting clinical information as a version to a second location in thememory store, the second location in the memory store containing one ormore versions of the clinical information.
 24. The method of versioningclinical information as claimed in claim 23 further comprising the stepsof: collecting updated clinical information from the user; and storingthe updated clinical information in the first location of the memorystore.
 25. An apparatus for visually playing back versioned informationto a user in a graphical user interface comprising: means for displayinga first version of the versioned information to the user in thegraphical user interface; means for selecting a second version of theversioned information including a slider control, the slider controlbeing displayed in the graphical user interface, the user adjusting theslider control thereby providing a version selection signal; and meansfor retrieving the second version of the versioned information, themeans for retrieving receiving the version selection signal andretrieving the second version, the means for displaying the secondversion.
 26. An apparatus for clinical contextual encounter between apatient and a clinician in an electronic medical records informationsystem comprising: means for receiving new clinical information relatedto the patient into the electronic medical records information system;means for recognizing a fundamental unit of medical observation of thenew clinical information; means for retrieving historical clinicalinformation related to the patient from a memory store, the historicalclinical information being of the same type of the fundamental unit ofmedical observation; and means for presenting the new clinicalinformation and the historical clinical information to the clinician,whereby a trend in the fundamental unit of medical observation isthereby displayed.
 27. A method of clinical contextual encounter betweena patient and a clinician in an electronic medical records informationsystem comprising the steps of: receiving new clinical informationrelated to the patient into the electronic medical records informationsystem; recognizing a fundamental unit of medical observation of the newclinical information; retrieving historical clinical information relatedto the patient from a memory store, the historical clinical informationbeing of the same type of the fundamental unit of medical observation;and presenting the new clinical information and the historical clinicalinformation to the clinician, whereby a trend in the fundamental unit ofmedical observation is thereby displayed.
 28. The apparatus as claimedin claim 26, further including means for analyzing the new clinicalinformation and the historical clinical information and means forproviding an opinion.
 29. The apparatus as claimed in claim 28, whereinthe opinion is a diagnosis.
 30. The method as claimed in claim 27,further including the steps of analyzing the new clinical informationand the historical clinical information and providing an opinion.
 31. Anon-transitory memory for storing health information for access by anapplication program executed on a data processor or data processingsystem, the non-transitory memory comprising: a data structure stored inthe memory, the data structure including health information resident ina database; a plurality of granule information data structures, each ofthe granule information data structures having a collection of genericattributes and a global unique identifier attribute; a plurality ofclinical observations, each of the clinical observations including acollection of the granule information data structures, each of theclinical observations having a collection of clinical attributes, andeach of the clinical observations being stored as a single database rowentry with the global unique identifier attribute in a metadata column;a plurality of clinical information data structures, each of theclinical information data structures including a base information datastructure and a clinical category information structure, each said baseinformation data structure including the collection of granuleinformation data structures which are included in at least one of theclinical observations, and each said clinical category information datastructure mapping the clinical attributes of the said at least one ofthe clinical observations to the generic attributes of the granuleinformation data structures included in said at least one of theclinical observations; and an attribute database in the base informationdatabase structure of each of the clinical information data structuresto allow new generic attributes to be added, wherein the granuleinformation data structures are agnostic of the clinical observationsand new said granule information data structures inherit the baseinformation data structures of the clinical information data structuresfrom which the new granule information data structures are created orderived, thereby allowing new said generic attributes to be added to thenew granule information data structures without altering an existingarchitecture of the flat file database.